\section{Security}\label{sec:Security}\index{security}

\subsection{Introduction}

In a secure installation, R-GMA services are responsible for ensuring
the integrity and confidentiality of the virtual databases and all
user data held within the service infrastructure.  This chapter
specifies the security mechanisms used by the services to meet this
responsibility. Sites can opt to run their services with these
security mechanisms turned off, but other R-GMA services running
securely will not communicate with them.

\subsection{Risks to services and data}

The integrity of a virtual database is compromised if a person
maliciously modifies data or causes operations to execute incorrectly
so that the virtual database reaches an invalid state or returns
invalid results. This can be achieved either by direct attacks on the
service infrastructure or by abusing the operations provided by
services.

The integrity and confidentiality of user data are compromised if a
person can read or modify the data without the owner's consent. User
data in R-GMA does not just include tuples, but also query strings
(because predicates may contain user data), resource connection
details (because these could be used to launch attacks), user
identification details stored for security purposes and user names and
passwords for external data stores.  Data integrity and
confidentiality can be compromised by a malicious person making direct
attacks on the service infrastructure or abusing the operations
provided by services. They can also be compromised by the failure of a
service implementation to properly enforce data access rules.

\subsection{Securing services and data}

The service infrastructure consists of the underlying operating
system, the servlet container, external
storage used by the services (e.g. databases, configuration files, log
files), connections between services and external storage (e.g. JDBC
links), and network connections to services. With the exception of the
network connections, it is beyond the scope of this specification to
say how these can be made secure, but it is mandatory for all R-GMA
service implementations to address the security of each of these
components.

How R-GMA services secure network transfers against interception and
modification, how they control connections to services and how they
control execute access to operations and read and write access to data
stores, are all covered in the remainder of this chapter.

\subsection{Securing network transers}

All user-to-service and service-to-service connections (including
streaming) in a secure R-GMA installation use SSL to encrypt the data
as it travels over the network. Data is \textit{not} encrypted by
R-GMA within its services. If users don't trust the security of
R-GMA's services, they must encrypt the data themselves before sending
it to R-GMA.
                                                                               

\subsection{Authentication}\index{authentication}

R-GMA services must immediately terminate a user's or other service's
attempt to connect to them if their identity cannot be
authenticated. If a user chooses to use one of the R-GMA APIs, the API
will likewise abandon a connection immediately if it cannot
authenticate the service to which it is connecting (this is
\textit{mutual authentication}). The APIs return an appropriate
RGMASecurityException in response to authentication failures.

Mutual authentication is based on an exchange of encrypted messages.
Each party's identity is proved by their possession of a private key
corresponding to the public key embedded in a digital certificate
signed by a certificate authority recognised by the other party.  Currently
R-GMA services accept only X509 format certificates (including proxy certificates generated by
grid-proxy-init or voms-proxy-init).

The mechanism used for authentication and for managing Certificate
Authority (CA) certificates and their supporting files (revocation
lists, signing policies, etc) is implementation-dependent.

\subsection{Authorization}\index{authorization}

\subsubsection{Credentials}\index{credentials}

R-GMA services permit or deny access to resources (in the general
sense) to a user or another service, on the basis of
\textit{credentials} held by that user or service. Credentials are
extracted from the certificate used for authentication in some
implementation-defined way. Each credential has a name such as the
{Distinguished Name} (DN) credential found in all
certificates\footnote{The DN of host certificates contains the host
name.}.  The credentials found in the \textit{VOMS proxy certificates}
used by all EGEE services are:

\begin{itemize}
\item Membership of virtual organizations (VO);
\item Membership of groups within a virtual organization (GROUP);
\item Roles held within a virtual organization (ROLE);
\end{itemize}

and some, such as GROUP, may take more than one value.  All
authorization rules are defined in terms of combinations of zero or
more credentials, and whilst R-GMA service implementations are obliged
to support VOMS credentials, they will actually work with any type of
credential.

\subsubsection{Ownership}\index{ownership}

The servers on which R-GMA services run are owned by individual
sites\index{site}, so it is they who decide whether or not to run the
services. 

Each virtual database has an owner (typically a VO) and registry 
instances and the master schema are hosted by sites by mutual agreement with the
virtual database owner. The virtual database owner owns the registry and schema instances and
decides who can read or modify them, but they have to trust the individual
sites to implement their policy, and the sites retain overall control.

Virtual database owners control who can create, read or modify information
the schema and who can read tuples from their virtual database and who can
publish tuples to it, because they own the schema and the data access rules are
defined there. Anybody permitted to write to a table defintion in the
schema can also control who can read or write to that table within the virtual
database.

\subsubsection{Authorization points}

Access to the tuples in the tuple stores is authorized using \textit{read} and 
\textit{write} rules set for each table and view in the schema. The rule-based 
mechanisms are described below.

Access to the schema information is controlled by rules stored as part of the
VDB in addition to rules stored with a table defintion in the schema.

\subsubsection{Restricting access to columns (views)}\label{sec:SecurityViews}\index{view}

Views are defined in the schema as a subset of the columns of a table
(the \textit{base table} of the view), created using the Schema
service's \textit{createView} operation (see
\ref{sec:SQLCreateView}). Users can query views just as they would
real tables, but they are read-only, so producers cannot publish to
them, and they do not appear in the registry. Their purpose is to
limit access to only certain columns of the base table: tuples read
from a view are actually read from the base table, but the query is
only allowed to include columns that form part of the
view. Authorization rules for row access to views are defined exactly
as for tables (see the next section) and completely replace the rules
on the base table.

\subsubsection{Authorizing read/write access to rows in tables or views}

All consumers (including those used by Secondary Producers) require read
authorization to read tuples from views or tables in the virtual database and
all producers (Primary, Secondary and On-demand) require write authorization
to publish tuples into tables in the virtual database.

These authorization rules are defined in the schema and the virtual database
owner decides who can change authorization rules in the schema by authorizing
the change operation as described above; the user who creates the table or view
sets the initial rules.

The producer services are responsible for enforcing the rules. In a Primary
Producer service, the write rules are applied in calls to \textit{insert} and
\textit{insertList}, and the read rules are applied in calls to \textit{start}.
In a Secondary Producer service, the write rules are ignored but the read rules
are applied as in a Primary Producer service. In an On-demand Producer service,
the write rules, followed by the read rules, are both applied in calls to
\textit{start}. In all cases, the producer services must
notice changes to the data access rules
and apply the changes to any tuples subsequently sent to a consumer service.
Note that enforcing read rules in the producer services requires the consumer
services to be able to prove that they are acting on behalf of the user or
service to which read access is being granted (this requires \textit{delegation}
of credentials).

The default rule is that no user is permitted any access to the table or view.
Rules are added to grant access only (not to deny it) and they are cumulative.
Read and write rules are formatted identically and have
the form ``\textit{predicate : credentials : action}'', where the three
clauses are defined as follows:

\begin{description}

\item[predicate]
Defines the subset of rows of the table or view to which this rule grants
access. It is an SQL WHERE clause that compares the values in specified
columns with constants, other columns or credential parameters (credential
name in square brackets, such as [DN]) that are replaced by the corresponding
credentials (or set of credentials) extracted from the user's certificate when
the rule is evaluated. The predicate expression is restricted to the following
operators: AND, OR, NOT, IN, \(=\), LIKE, \(<>\), \(<\), \(>\) and IS
NULL. This clause may be empty, in which case the rule applies to all rows in
the table.

\item[credentials]
Defines the set of credentials required for a user to be granted access to
the subset of rows defined by this rule. It is a boolean combination of
equality constraints of the form \textit{[credential] = constant}. This
clause may be empty, in which case the rule applies to all authenticated
users.

\item[action]
Defines what any matching user is allowed to do to the subset of rows defined
by this rule. The valid values are: \textit{R} (read), \textit{W} (publish) or
\textit{RW} (read and publish). This clause must not be empty.

\end{description}

Some examples rules are:

\begin{verbatim}
WHERE Section = 'Marketing':[GROUP] = 'Marketing' OR [GROUP] = 'Management':RW
\end{verbatim}

that grants read-write access to any authenticated user with a GROUP
credential of 'Marketing' or 'Management', to those rows that contain the
value 'Marketing' in the 'Section' column;

\begin{verbatim}
WHERE Owner = [DN]::R
\end{verbatim}

that grants read-only access to any authenticated user, to those rows that
contain the value of their DN credential in the 'Owner' column;

\begin{verbatim}
WHERE Group = [GROUP] OR Public = 'true'::R
\end{verbatim}

that grants read-only access to any authenticated user, to those rows
that contains one of their GROUP credential values in the 'Group' column, or
have a value of 'true' in the 'Public' column;

\begin{verbatim}
::R
\end{verbatim}

that grants read-only access to any authenticated user, to all rows in the
table.

\subsubsection{Authorizing access to the schema}
This is controlled by similar rules but without a predicate so the take the
form: ``\textit{credentials : action}'' and so can be distinguised by having
only one ``:``. Possible actions are: \textit{R} (read or list schema entry),
\textit{W} (write - i.e. modify an existing schema entry), \textit{C}
(create a table) or any permutation of these letters. An empty authorization
is not permitted. Rules may be stored with the table defintion in the schema as
well as in the defintion of the VDB. The  \textit{C} action is only permitted in
the VDB definition (there is no meaning to telling a table that it can create
itself). Rules only allow operation and do not deny them. As a consequence if
a VDB has decided to have a policy of :W then all users of the VDB can modify any table defintion
and the creator of a table is unable to restrict this.

\subsection{Proving services are genuine}

Users determine that R-GMA services are genuine by obtaining their URLs from
a trusted source. R-GMA Producer and Consumer services only connect to
local Registry and Schema services, and only connect to Producer and Consumer
services whose URLs were passed to them by other R-GMA services that they have
authenticated and authorized. R-GMA services however communicate with one
another and no delagtion mechanism is in use. Instead the set of servers is a
part of the VDB definition so the VDB defintion must be carefully controlled.
